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Fundamentals 
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Case  Study 

Summary 

Addendum 

•  Reading  list 

•  Additional  analytical  tools 

•  Additional  illustration 

•  Change  agent  references 

•  CMMI  Process  Areas 
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Objectives 


Review  Six  Sigma  fundamental  concepts  and  benefits. 

Share  tips  on  Six  Sigma  implementation  and  training  in  a 
systems  and  software  environment. 

Offer  perspectives  on  the  synergy  between 
software/systems-specific  initiatives  and  Six  Sigma. 

Illustrate  several  analytical  tools  for  potential  application  in 
systems  engineering  and  software  development. 

Share  a  “real  story”:  Details  of  Lockheed  Martin 
Management  &  Data  Systems  technology  change 
management  project. 
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Outline 

Objectives 

Fundamentals 

Implementation 
The  “Black  Belt”  Project 
Case  Study 
Summary 
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Brief  History 


1979  -  Motorola  quality  imperative  “roots  of  Six  Sigma” 

1981  -  Motorola  challenge  to  improve  10  fold  in  5  years 
1988  -  Motorola  wins  Malcolm  Baldrige  Quality  Award 

1991  -  Motorola  Six  Sigma  Research  Institute  established 

1992  -  Motorola,  Texas  Instruments,  IBM,  Kodak,  and  others 

initiated  efforts  to  develop  the  6a  Black  Belt  program 

1995  -  GE  mandates  Six  Sigma  rollout;  estimates  current 
performance  at  3.5  Sigma 

1997  -  GE  invests  $250M  to  train  4,000  Black  Belts  and  60,000 

Green  Belts  out  of  workforce  of  222,000;  recoups  $300M 
same  year 

1 998  -  GE  calculates  Six  Sigma  payoff  at  $1 .25B 

[Stoddard  00] 
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Who  Uses  Six  Sigma? 


Lockheed  Martin 
Boeing 

General  Electric 
Hewlett  Packard 
Honeywell 
Motorola 

Northrop  Grumman 

Raytheon 

Rohr 

TRW 


compiled  from  variety  of  news  articles,  web  references  and  conference  presentations 
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Who  Else  Uses  Six  Sigma? 


3M 

Amazon.com 
American  Express 
Bank  of  America 
Black  &  Decker 
Bombardier 
Citigroup 
DuPont 

Eastman  Kodak 
Ford 

General  Motors 


JP  Morgan 
Lantech 
Pella  Windows 
Polaroid 
Porsche 

Sony  Electronics 
Toshiba 
Toyota 
Volkswagen 
Wire  Mole 


compiled  from  variety  of  news  articles,  web  references  and  conference  presentations 
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What  Is  Six  Sigma? 

•  a  philosophy 

•  a  performance  measurement 

•  an  improvement  framework 

•  a  set  of  improvement  tools 

•  a  structured  approach  for  business  improvement  (a 
business  strategy) 
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Six  Sigma  Philosophy 

Improve 

customer  satisfaction 
by  reducing  and  eliminating 

defects 


Greater  Profits 
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Six  Sigma  Metrics 

Defect  Measures 

•  Defect  Rate,  parts  per  million  (ppm) 

-  “3.4  ppm”  -  most-cited  metric 

•  Sigma  Level 

•  Defects  per  Unit  (dpu) 

•  Defects  per  Million  Opportunities  (dpmo) 

•  Yield 

Practitioner  Project  Measures 

•  Defect  measures 

•  Cycle  time,  cost,  product  performance,  variability.... 

•  Bottom-line  savings 
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Example  Sigma  Levels 


[Harrold  98],  [Harry  00] 


Sigma  Level 

(ppm  for  shifted  process) 
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4  Sigma  in  Everyday  Terms 

4  Sigma  =  “99.9%  sure” 

•  9  hours/year  unsafe  drinking  water 

•  107  incorrect  medical  procedures  a  day 

•  200,000  incorrect  drug  prescriptions  per  year 

•  18,322  pieces  of  mishandled  mail  an  hour 

•  2,000,000  documents  lost  by  IRS  a  year 

•  Two  short  or  long  landings  at  any  major  airport  each 
day 


[Harrold  99],  [LMC  M&DS  training] 
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Statistical  Thinking 

Everything  is  a  process. 

All  processes  have  inherent  variability. 

Data  is  used  to  understand  variation  and  to  drive 
decisions  to  improve  the  processes. 


Data  Spread  due  to 
Common  Cause  Variation 


variation  will  re-establish  itself.) 


[ASQ  00],  [ASA  01] 
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In  Other  Words... 
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Operating  at  Six  Sigma  Implies 


Data-driven  decision  making 
Meeting  customers’  requirements 
Measurable  processes 
Processes  Under  Control 
Variation  has  been  reduced 
Future  performance  can  be  predicted 
Results  of  actions  can  be  assessed 


■n-SIX 

SIGMA 

WAY 

Hov  GE.  Motoiola 
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Six  Sigma  Improvement  Frameworks 

DMAIC 

•  Define  -  Measure  -  Analyze  -  Improve  -  Control 

•  used  to  improve  existing  processes  and  products 

DMADV 

•  Define  -  Measure  -  Analyze  -  Design  -  Verify 

•  a  process  of  “Design  for  Six  Sigma”  (DFSS) 

-  there  is  not  unified  approach  to  DFSS  across  industry 

•  used  to  design  new  products  and  processes 

•  used  to  redesign  an  existing  process  which  has  been 
optimized  but  still  does  not  meet  specifications 


Both  emphasize  customer  satisfaction  and  business  benefit. 
Both  focus  on  critical  to  quality  characteristics. 
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Toolkit 


Define 

Measure 

Analyze 

Improve 

Control 

Benchmark 

Baseline 

Contract/Charter 
Kano  Model 

Voice  of  the 
Customer 

Voice  of  the 
Business 

Quality  Function 
Deployment 

Process  Flow 
Map 

Project 

Management 

"Management 
by  Fact" 

Defect  Metrics 

Data  Collection 
Methods 

Sampling 

Techniques 

Measurement 
Sys.  Evaluation 

7  Basic  Tools 

Cause  &  Effect 
Diagrams,  Matrix 

Failure  Modes  & 
Effects  Analysis 

Statistical 

Inference 

Reliability 

Analysis 

Root  Cause 
Analysis 

5  Whys 

Hypothesis  Test 
ANOVA 

Design  of 
Experiments 

Modeling 

Tolerancing 

Robust  Design 

Systems 

Thinking 

Decision  & 

Risk  Analysis 

Statistical 

Controls: 

•  Control  Charts 

•  Time  Series 
methods 

Non-Statistical 

Controls: 

•  Procedural 
adherence 

•  Performance 
Mgmt 

•  Preventive 
activities 
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Outline 

Objectives 

Fundamentals 

Implementation 

The  “Black  Belt”  Project 
Case  Study 
Summary 
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Roles 

Executive  Management 

•  support  of  top  management  is  required 

Champions 

•  identify  projects,  select  “belt”  candidates,  remove  barriers 

Master  Black  Belts 

•  train  and  mentor  Black  Belts 

•  typically  work  with  Black  Belts  and  process  owners  in  a 
functional  area  or  business  unit 

Black  Belts  -  the  “heart  and  soul”  of  Six  Sigma  initiatives 

•  lead  improvement  projects 

Greenbelts 

•  support  black  belt  projects  or  lead  smaller  projects 

•  typically  part-time 
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Training  and  Certification 

Green  Belt 

•  typical  training:  1  week  to  2  weeks 
Black  Belt 

•  DMAIC  training:  4  to  5  weeks  over  6  months  with  project 

•  DFSS  training:  2  to  3  weeks  over  6  months  with  project 

•  certification: 

-  completion  of  certification  project 

-  completion  of  training 

-  often  rated  on  demonstration  of  skills 

Master  Black  Belt 

•  role  earned  by  experience  and  demonstrated  project 
successes 
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The  “Black  Belt”  Practitioner 


Expectations: 

•  Influence  change 

•  Provide  leadership  in  applying  quantitative  methods 

•  Facilitate  teamwork 

•  Consult  with  management 

•  Transfer  knowledge  and  skills  to  others 

•  Discover  new  leveraging  opportunities 

•  Continuously  improve  their  skills 

•  Participate  in  the  Black  Belt  network 


[kodak.com] 
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Juggling  Multiple  Initiatives? 


®  Capablity  Maturity  Model,  CMMandCMMI  are  registered  in  the  U.S.  Patent  and  Traderrark  Office  by  Camege 
Mellon  University. 

SM  CMM  Integration,  Personal  Softvvare  Process,  PSP,  Team  Software  Process  andTSP  are  service  rrarks  of  Carnegie 
Mellon  University 
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SPC’s  Frameworks  Quagmire 
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CMMI  Staged  and  Six  Sigma 


•  Organization-wide  6a  improvements  and  control 
I  •  Correlation  between  key  process  areas  &  6a  methods 
I  •  6a  used  within  CMM  efforts 


Optimizing 


Process 
improvement 


0  •  Infrastructure  in  place 
•  Defined  processes  feed  6a 


Quantitatively 
Manaaed 


Process  measured 
and  controlled 


Process  characterized  for  the 
organization  and  is  proactive 


6a  philosophy  &  method  focus 
6a  “drilldown”  drives  local 
(but  threaded)  improvements 
6a  may  drive  toward  and  Drnrocc i 
accelerate  CMMI  solution 


Managed 


Process  characterized  for  projects  and 
is  often  reactive 


Process  unpredictable  and  poorly  controlled 


Six  Sigma  is  enterprise  wide. 

Six  Sigma  addresses  product  and  process. 

Six  Sigma  focuses  on  “critical  to  quality”  factors. 
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CMMI  Continuous  and  Six  Sigma 


Achieve  high  capability  in  PAs  that  build  Six  Sigma  skills. 
•  MA,  QPM,  CAR,  OPP 

Use  capability  to  prioritize  order  of  remaining  PAs 


Remaining  PAs  ordered  by  business 
factors,  improvement  opportunity,  etc. 

[vickroy  03]  (understood  using  foundational  capabilities) 

©  2003  by  Carnegie  Mellon  University 


page  26 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


CMMI  and  Six  Sigma: 

Additional  Considerations 

Six  Sigma  applications  “around”  CMMI 

•  SEPG  process  improvement  rollout 

•  Appraisal  methods 

Organization  certifications 

•  CMMI:  appraisals 

•  Six  Sigma:  performance  is  evidenced  by  bottom  line  results 
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A  Mathematical  View 


y1  =  customer  satisfaction 
y2  =  profitability 

•  note  that  profitability  has  a  dependence  on  customer  satisfaction 
x1  =  standards,  engineering  practices/processes 

•  what  to  do,  what  is  done 

•  as  characterized  and  measured  by  capability  models 

xk’s  =  product  innovation,  organization  policies,  marketplace  factors  and  so 


on 


In  this  view,  cost,  quality,  schedule,  product  features  are  “intermediate”  responses: 
functions  of  standards  &  practices,  factors  for  customer  satisfaction  and  profitability. 


Six  Sigma  is  a  way 
to  define  the  axes, 

to  traverse  the  response  surface  and  find  the  optimum. 
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Tailoring  Training  for  SW/SE 


Leverage  software  and  systems-specific  measurement 
training  as  part  of  the  DMAIC  curriculum 

Use  projects  to  build  repository  of  examples  of  analytical 
methods  in  context  of  systems  and  software 

Extend  Six  Sigma  curriculum,  for  instance 

•  Bayesian  modeling 

•  Rayleigh  distributions 

•  reliability  fault  trees 

Develop  an  in-class  design  project  suitable  for  systems 
and  software  engineering 
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Tailoring  Implementation  for  SW/SE 


Business  objectives  should  drive  the  effort 
Leverage  existing  roles 

•  Select  engineering  process  group  members  as 
sponsors,  possibly  as  Champions  and  Black  Belts. 

Mapping  methods 

•  Integrate  the  practices  of  models,  standards,  and 
initiatives  into  a  unified,  holistic  approach  that  is 
appropriate  for  your  organization. 
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LMC  M&DS  Training  &  Implementation 


Executive  Lean  Training 

•  Top  Executives  -  one  week  off  site 

•  Must  understand  and  promote 

Green  Belt  Training 

•  One  week  course  (corporate  initiated/  unit  led) 

•  Certification  (completion  of  course,  1  event,  Black  Belt  Mentor) 

•  Considering  expanding  Green  Belt  training  to  keep  Black  Belt 
training  at  three  weeks 

Black  Belt  Training 

•  Three  week  DFSS/Lean  course  (corporate  initiated) 

•  Certification  (completion  of  course,  3  events,  mentored  one 
greenbelt  to  certification) 
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LMC  M&DS  Training  &  Implementation  2 

Lean  Event  Training 

•  2-hour  training  session  opens  each  lean  event 

•  covers  tools  and  methodologies 

•  geared  for  those  without  previous  experience 


Organizational  Training  Goals 

•  green  belts  to  be  trained  set  annually 

•  black  belts  to  be  trained  set  annually 


©  2003  by  Carnegie  Mellon  University 


page  32 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


LMC  M&DS  Process  Standard 

Program  Process  Standard  (PPS) 

•  minimum  mandatory  set  of  development  processes 

•  updated  using  industry  standards  in  which  certifications  were 
desired 

Example:  Quantitative  Management 

•  Key  elements 

-  program  process  standards 

-  metrics  program 

•  Map  to  CMMI  Organizational  Process  Performance  (OPP) 

-  SGI :  Establish  performance  baselines  and  models 

•  Map  to  ISO  9001  -2001 

-  5.1  Management  Commitment 

-  5.4.1  Quality  Objectives.... 

•  and  so  on 
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LMC  M&DS  Process  Standard  Roadmap 


CMMI  SE/SW  Vl.l  -  2002 


4.1.1  Supply  Process 
R1 :  Product  Supply 
ling  Process 

’rocess  Implementation  Strategy 
.5:  Technical  Effort  Definition 


ISO/IEC  12207  -  1995 


7.3  Improvement  process 


5.3.1  Process  implementation 
7.3  Improvement  process 


.2.4  Planning 
5.2.5  Execution  &  control 
,4  Training  process 


0.8  Problem  resolution  process 
7.3  Improvement  process 


iUUL 

re\ 

rorovk 

^N^echnical  Plans  — ■ — 

"T 5~7 

6.1 

62 

6.3/  ytftyl 
6.0 ymnt  re\l 
IX Manage! 
7.2  Infrastrul 
7.4  Training! 

’Six  Sigma  links: 


Level  2  Measurement  &  Analysis  PA,  Level  4/5  PAs 
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Exercise:  Important  Concepts 

Form  groups  of  4. 

Each  person  takes  a  turn  and  shares 

•  the  initiatives  being  juggled  in  his  or  her  organization 

•  the  most  important  or  relevant  concept  from  the  first 
sections  (fundamentals,  implementation). 

Total  time  for  exercise:  12  minutes 


©  2003  by  Carnegie  Mellon  University 


page  35 


CarnecpeMellon 

Software  Engineering  Institute 


Outline 

Objectives 

Fundamentals 

Implementation 

The  “Black  Belt”  Project 

•  project  basics 

•  analytical  tools 
Case  Study 
Summary 


©  2003  by  Carnegie  Mellon  University 


page  36 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


What  is  a  Defect? 


Six  Sigma:  Any  product,  service,  or  process  variation  which  prevents 
meeting  the  needs  of  the  customer  and/or  which  adds  cost,  whether  or 
not  it  is  detected. 

Personal  Software  ProcessSM  (PSPSM):  Defects  or  faults  are  the  result 
of  errors  or  mistakes.  At  a  minimum,  count  a  defect  every  time  the 
program  is  changed  during  compile  or  test,  where  the  change  might  be 
one  character  or  multiple  statements 

ISO  9000:2000:  Defects  are  the  non-fulfillment  of  a  requirement  related 
to  an  intended  or  specified  use. 

Software  Reliability:  An  error  is  a  discrepancy  between  a  computed, 
observed  or  measured  value  and  the  true  value  or  a  human  action  that 
results  in  software  containing  a  fault.  A  failure  is  the  inability  to  perform  a 
required  function  with  specified  limits.  A  fault  is  a  defect  in  the  code  that 
can  be  the  cause  of  one  or  more  failures. 


[Humphrey  95],  [DACS] 
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Defect  Consequences  Worksheet 

List  the  consequences  of  different  types  of  defects. 


Event 

Consequence 

Customer  complaints 

Escaping  defects 

Test  defects 

Inspection  defects 

Note:  This  worksheet  is  provided  for  your  notes  about  the  consequences  of  different 
types  of  defects  in  your  organizational  context.  It  may  be  completed  after  the  tutorial. 
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False  Starts  on  SW  Sigma  Metrics 


From  Motorola: 

Single,  over-riding  objective  is 

Customer  Satisfaction: 

“the  degree  of  confidence  a 
customer  has  that  his  (or  her) 
product ...  expectations  will  be  met 
by  the  producer.” 


#  late 
arrivals 

bags  lost 

[Stoddard  00],  [Stoddard  02] 
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The  Customer’s  Vantage  Point 


32-step  “workaround”  to  move  info  to  new  version  of  financial 
software 

Wrong  “Statement  Ending  Balance”  when  reconciling  a  mutual 
fund  account  using  financial  software 

Bank  ATM’s  debit  accounts  but  don’t  give  money 

University  students  unable  to  enroll  due  to  lingering  problems  in 
multi-million-dollar  software  system 

New  air  traffic  control  system  out  of  action  more  than  7  hours 
resulting  in  cancelled  flights  and  extended  delays 

Carrier  plane  veers  right  without  warning  due  to  computer  glitch 
(emergency  landing  was  a  result) 

Money  from  payroll  direct  deposits  missing  from  bank  accounts 

[NYT],  [SM] 
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What  “Sigma  Level”  is  “Right”? 


What  is  your  customer  telling  you? 

Plus,  a  general  business  perspective: 

•  A  4  sigma  company  spends  >10%  of  revenues  on 
internal  &  external  repair 

•  A  6  sigma  company  spends  <1%  of  revenues  on 
internal  &  external  repair 

At  LMC 

•  processes  modeled  using  SWEEP*  tool 

-  allows  tolerances  to  be  set  based  on  present 
performance 

-  allows  targets  to  be  set  based  on  future  performance 

•  output  of  the  modeling  showed  “six  sigma”  performance 

*SWEEP  =  Software  Error  Estimation  Program 
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What  Is  a  Black  Belt  Project? 

Business  importance 

•  Financial  expectations:  $100-150K  (US)  savings,  at  least 

•  Endorsed  and  approved  by  management 

Duration:  3-6  months  recommended 

Objectives  are  quantitative  and  include  at  least  one  of  the  following: 

•  Improve  customer  satisfaction. 

•  Optimize  the  supply  chain. 

•  Reduce  defects. 

•  Reduce  cycle  time. 

•  Improve  first-pass  yield. 

•  Reduce  variability. 

•  Optimize  product  performance. 

•  Optimize  process  performance. 

•  Reduce  costs. 

•  Reduce  the  cost  of  quality. 

[kodak.com],  [Snee  01] 
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Composite  Project  Illustration 


Problem  and  goal  statement  (Y): 

•  maximum  latent  defects  released 

•  minimum  mean  time  between  failure  in  the  field 

•  time  to  market  improvement  (as  function  of  test  time,  defect  density) 


I 

•  Problem  &  goal 
statements 

•  Define  boundaries 

•  Process  maps 

•  “Management  by  Fact” 


¥ 

•  Discovery:  paretos,  histograms,  distributions,  c&e 

•  Understanding:  root  cause,  critical  factors 

•  Improvement:  adjust  critical  factors,  redesign 

•  Performance:  on  target,  with  desired  variation 

Y  =  f(defect  profile,  yield) 

=  f(review  rate,  method,  complexity . ) 
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A  Very  High-Level  Process 


Engineering  Support  Processes 


Program  Management  &  Control  Processes 


Organizational 

Processes 


Define  and 
Improve  SE 
Processes 


and  I  I  Me 
sSE  Pr 

ises  |  |  Ev< 


Manage 

Product 

Evolution 


Manage  SE 
Support 
Environment 


Knowledge 

Mgmt 


Supplier/ 
Subcontractor 
Coordination 
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Project  Boundaries  Process  Map 


Design 


O  Requirements 
*  Estimate 
O  Concept  design 


> 


Code 

5 

-> 

Compile 

O  Resources 

*  Code  Stds 

*  LOC  counter 

*  Interruptions 

r 

O  Code 

Unit 

Test 


> 


O  Executable  Code 

•  Test  Plan,  Technique 

•  Operational  Profiles 


•  Detailed  Design 

•  Test  cases 

•  Complexity 

•  Data:  Design  Review 
defects,  Fix  time, 
Phase  duration 


•  Code 

•  Data:  Defects, 
Fix  time,  Defect 
Injection  Phase, 
Phase  duration 


•  Executable 
Code 

•  Data:  Defects, 
Fix  time,  Defect 
Injection  Phase, 
Phase  duration 


•  Functional 
Code 

•  Data:  Defects, 
Fix  time,  Defect 
Injection  Phase, 
Phase  duration 


A 

Inspection 

O 

Critical  Inputs 

\ 

*  Standard  Procedure 

O 

V 

Rework 

t 

Noise 

•  Control  Knobs 

_ y 
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Drilldown  to  Inspection  Process 

What  are  the  sources  of  variation?  the  control  knobs? 


O  Artifacts  to 
inspect 

#,  *  Artifact  size 

•  Reviewers 

*  Data  repository 


O  Review  Rate 
O  ,  *  Checklists 
#,  *  Inspection 
method,  procedure 
*  Proficiency 
fi  Taxonomy 
interpretations 


What  would 
you  list? 


What  would 
you  list? 


Defect  Log  •  Direct  Cause  •  Corrective 
Record  of  plan  •  Root  Cause  Action 


\ 

o 

Critical  Inputs 

t 

Noise 

* 

Standard  Procedure 

• 

Control  Knobs 

V 

_ J 

Data  feed  DMAIC 
project  process 
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Starting  Out.... 

Collecting  basic  data 

Refining  processes 

•  inspections 

Improving 

•  cause  &  effect  matrix 

•  pareto  analysis 

Leads  to 

•  injecting  fewer  defects 

•  detecting  defects  earlier 

•  removing  them  efficiently 

•  process  stability 
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Design  Code 

Review  Review 


Post-Improvement  Defect  Density 


Design  Code 
Review  Review 
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Rayleigh  Distribution 


Error  Discovery  Data  and  Rayleigh  Fitted  Histograms 


Preliminary  Detailed  Code  &  Unit  Integration  System  Test  Deployment 
Design  Design  Test 


©  2003  by  Carnegie  Mellon  University 


age  4i 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  M A 


Cause-Effect  Model  Using  Bayesian  Modeling 


[Stoddard  02] 
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CASRE*  Predictions 

Bivariate  Fit  of  Actuals  By  Predicted 

60  1 - 

u)  50  _ 

03  40  - 
o  30  - 

<  - 

20  - 

10 

0  0  10  20  30  40  50  60 

Predicted 

Actual  field  defects  =  f(CASRE  predicted  defects) 

CASRE  predicted  defects  =  f(weekly  arrival  rate  of  SW 
failures,  weekly  test  intensity  measures ) 

$3M/year  savings  from  premature  SW  releases 

[Stoddard  02],  *CASRE  =  Computer  Aided  Software  Reliability  Estimation 
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Outline 

Objectives 

Fundamentals 

Implementation 

The  “Black  Belt”  Project 

•  project  basics 

•  analytical  tools 

Case  Study 
Summary 
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Toolkit 


Define 

Measure 

Analyze 

Improve 

Control 

Benchmark 

Baseline 

Contract/Charter 
Kano  Model 

Voice  of  the 
Customer 

Voice  of  the 
Business 

Quality  Function 
Deployment 

Process  Flow 
Map 

Project 

Management 

"Management 
by  Fact" 

Defect  Metrics 

Data  Collection 
Methods 

Sampling 

Techniques 

Measurement 
Sys.  Evaluation 

7  Basic  Tools 

Cause  &  Effect 
Diagrams,  Matrix 

Failure  Modes  & 
Effects  Analysis 

Statistical 

Inference 

Reliability 

Analysis 

Root  Cause 
Analysis 

5  Whys 

Hypothesis  Test 
ANOVA 

Design  of 
Experiments 

Modeling 

Tolerancing 

Robust  Design 

Systems 

Thinking 

Decision  & 

Risk  Analysis 

Statistical 

Controls: 

•  Control  Charts 

•  Time  Series 
methods 

Non-Statistical 

Controls: 

•  Procedural 
adherence 

•  Performance 
Mgmt 

•  Preventive 
activities 
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“Tool  Tips”  Outline 

Reference  overview  (description,  procedure,  tips, 
examples)  for 

•  Management  by  Fact 

•  Voice  of  the  Customer 

•  Process  Mapping 

•  7  Basic  Tools 

•  Lean 

Brief  highlights  for 

•  Cause  and  Effect  Matrix 

•  Quality  Function  Deployment 

•  Bayesian  Modeling 

•  Systems  Thinking 
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Tool  Tip:  Management  by  Fact  (MBF) 

Description  (CMMI  M&A,  QPM,  CAR) 

•  a  concise  summary  of  quantified  problem  statement, 
performance  history,  prioritized  root  causes  and 
corresponding  countermeasures  for  the  purpose  of 
data-driven  project  management 

Management  by  Fact 

•  uses  the  facts 

•  eliminates  bias 

•  tightly  couples  resources  and  effort  to  problem-solving 
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MBF:  Procedure 


Identify  and  select  problem  (M&A,  QPM) 

•  use  “4  Whats”  to  help  quantify  the  problem  statement 

•  quantify  gap  between  actual  and  desired  performance 

Determine  root  cause  (M&A,  CAR) 

•  separate  beliefs  from  facts 

•  use  “7  Basic  Tools” 

•  use  “5  Whys” 

Generate  potential  solutions  and  select  action  plan  (M&A,  OID) 

•  Must  be  measurable/sustainable 

•  Specific/assignable  ownership 

•  Understand  expected  results  from  each  action 

Implement  solutions  and  evaluate  (M&A,  OPP,  OID) 

•  Compare  data  before  and  after  solution 

•  Document  actuals  and  side  effects 

•  Compare  with  desired  benchmark 
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4  Whats 


Customer  satisfaction  scores  are  too  low. 

•  What  is  too  low? 

Compared  to  best-in-class  benchmark  of  81%,  we  are  at  63%. 

•  What  is  the  impact  of  this  gap? 

It  represents  lost  revenue  and  earnings  potential? 

•  What  is  the  correlation  between  customer  satisfaction  and 
revenue? 

Each  percent  of  customer  satisfaction  translates  to  0.25 
percent  of  market  share  which  equals  $100M  US  revenue. 

•  What  is  the  lost  potential? 

Final  problem  statement: 

Customer  satisfaction  is  18%  lower  than  best-in-class 
benchmark,  which  corresponds  to  a  potential  lost  revenue  of 
$1.8B  US. 
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5  Whys 

The  marble  in  the  Jefferson  Memorial  was  deteriorating. 

•Why? 

The  deterioration  was  due  to  frequent  cleanings  with  detergent. 

•Why? 

The  detergent  was  used  to  clean  bird  droppings  from  local 
sparrows. 

•Why? 

The  sparrows  were  attracted  by  spiders. 

•Why? 

The  spiders  were  attracted  by  midges. 

•Why? 

The  midges  were  attracted  by  the  lights. 

Solution:  Delay  turning  on  the  lights  until  later  at  dusk. 
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MBF:  Format 


FACTUAL  STATEMENT  OF  PROBLEM,  PERFORMANCE 
TRENDS  &  OBJECTIVES 


Prioritization  & 
Root  Cause 

Counter  Measures  & 
Activities 

Impact,  Capability 

List  of  gaps  in 

List  of  specific  actions,  who 

List  of  expected 

performance  and  true 
root  cause 

has  ownership  and  due  date 

benefits  and  impact  of 
each  countermeasure 

Graph  of 

performance  over  time 


Graph  of  supportive 
or  more  detailed  information 
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MBF:  Example 

Problem  Statement _ 

Customers  A,  B  and  C,  representing  x%  of  market  share,  are  facing  budget/cost  constraints  and  require  a  10%  cost  reduction  in  our  product  line  XYZ  in 
order  to  continue  doing  business  with  us.  Baseline  data  shows  that  33%  of  software  development  time  is  spent  detecting  and  correcting  defects. 


200.0 
180.0 
“160.0 
3l  40.0 
*120.0 
ml  00.0 
o  80.0 

■S  60.0 

q  40.0 
20.0 
0.0 


Change  in  Defect  Density 


□  Pre- 
Im  prove 
ment 

■  Post- 
Im  prove 
ment 

— 

T 

lltz 

Ll 

Defect  Density 


Program 


Prioritization  &  Root  Cause 

Counter  Measures  &  Activities 

Who 

When 

Large  Quantity  of  Syntax  &  Similar  defects 
that  are  repaired  in  <10  minutes  on  avg 

Goal  is  50%  reduction  in  time,  relative  to 
historical  data 

Clarify  type  definitions 

jms 

v' 4/30/2001 

Improve  subcategory  data  collection 

jms 

S 4/30/2001 

Build  a  cause  &  effect  diagram  to  be  used  for  next  round  of 
analysis,  improvement  planning 

jms 

Increase  correction  efficiency  by  seeking  all  occurrences  of 
a  defect  upon  the  detection  of  the  first  occurrence 

jms 

v'. 4/30/2001 

Increase  and  log  (new)  usage  of  off-line  programs  to  test 
small  pieces  of  functionality 

jms 

Create  &  Use  a  syntax  checklist 

jms 

'k 4/30/2001 

"Big  Hitter"  (>10  minutes)  defects  involve 
a  variety  of  errors  that  escape  to  testing. 
Design-injected  and  Test-removed  errors 
fall  into  this  category 

Goal  is  25%  reduction  in  time,  relative  to 
historical  data 

Time  breaks:  phase  completion  &  every  hour 

jms 

S 4/30/2001 

Conduct  a  phase  check  prior  to  moving  on 

jms 

'k 4/30/2001 

Increase  and  log  (new)  usage  of  off-line  programs  to  test 
small  pieces  of  functionality 

jms 

'k 4/30/2001 

Improve  subcategory  data  collection  to  use  for  developing  a 
more  directed  design  review 

jms 

'k 4/30/2001 

Build  a  cause  &  effect  diagram  to  be  used  for  next  round  of 
analysis,  improvement  planning 

jms 
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Tool  Tip:  Voice  of  the  Client  (VOC) 

Description  (IPM  -  where  customer  is  part  of  group,  IPPD) 

•  a  method  to  describe  the  stated  and  unstated  needs  or 
requirements  of  the  customer 

•  can  be  captured  in  a  variety  of  ways:  direct  discussion 
or  interviews,  surveys,  focus  groups,  customer 
specifications,  observation,  warranty  data,  field  reports, 
complaint  logs,  etc. 


[isixsigma] 
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VOC:  Usage 

Feeds  Quality  Function  Deployment  (QFD) 

Risks  (track  via  RSKM  and  DAR  techniques) 

•  anecdotal,  not  quantitative 

•  difficult  to  get  “the  right  answer” 

•  humans  are  PERFECT  FILTERS! 

•  it  is  very  easy  to  induce  bias  in  VOC 

Tips 

•  use  existing  information  with  care  -  it  may  be  biased  or  too 
narrowly  focused 

•  always  use  more  than  one  source 

•  customer  visits  allow  direct  discussion  and  observation 

•  customer  visits  allow  immediate  follow-up  questions  and 
unexpected  lines  of  inquiry 
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VOC  Interviews:  Procedure  ■, 


Define  the  customer. 

Select  customers  to  interview. 

•  Always  interview  more  than  one. 

Plan  interview,  (use  verification  &  validation  techniques) 

•  Develop  a  checklist/guideline. 

•  Teams  of  3:  “Moderator,”  “Scribe,”  “Observer” 

Conduct  interviews,  (collect  metrics  for  trend  analysis) 

•  Customer  statements  &  observations  need  to  be 
recorded  VERBATIM. 

•  Keep  asking  “why.” 
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VOC  Interviews:  Procedure  2 


Create  VOC  table.  (RM,  RD) 

•  Interpret  verbatim  statements  into  new  meanings. 

•  Document  source  of  VOC  or  re-worked  VOC. 

-  “I”  if  internally  changed  or  generated  (by  team) 

-  “E”  if  externally  generated  (by  customer)  or  not 
changed  by  team 

•  Classify  each  statement  as: 

-  a  real  need  feeds  QFD 

-  a  technical  solution 

-  a  feature  requirement  feeds  QFD 

-  not  a  true  need  (e.g.,  cost  issue,  complaint, 
technology,  hopes  dreams,  etc.) 

•  Quantify,  Analyze,  Prioritize 
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VOC:  Example  Table 

New  process  initiative  under  consideration 

•  interview  statements  recorded  verbatim  and  classified 

•  column  added  for  keyword  sorting 

Further  development 

•  “interpreted”  comments  about  the  organization’s  true 
goals,  the  overlap  of  initiatives  (and  so  on) 

•  evaluation  for  common  themes 

•  additional  data  collection  may  be  needed 


Classification 

Customer  comment 

Interpreted,  reworded 

l/E 

perception, 

experience,  context 

barrier 

root  issue? 

results,  success 

need 

solutions 

Keyword 
for  sorting 

We  are  already  at  maturity  level 
x,  so  why  do  more? 

E 

✓ 

✓ 

competing 

initiatives 
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VOC:  Analysis 


Prioritization 

Method 

Customer 

Time 

Preparation 

Complexity 

Analysis 

Complexity 

Quality  of 
Resulting 
Prioritization 

Number  of 
customers 

needed 

Number  of 
Needs  to 
Prioritize 

Recommend 

Frequency  of 
Response 

short 

low 

low 

low 

large 

large 

NO 

Constant  Sum 

medium 

medium 

medium 

medium 

medium 

small 

Yes 

Rating 

short 

low 

low 

medium 

medium 

med-large 

Yes 

Simple 

Ranking 

medium 

low 

low 

medium 

medium 

small-med 

Yes 

Q-Sort 

short 

low 

low 

medium 

medium 

large 

Yes 

Paired 

Comparison 

long 

medium 

high 

high 

large 

small 

Yes 

Regression 

short 

medium 

high 

high 

large 

small-med 

Yes 

©  2003  by  Carnegie  Mellon  University 


66 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


Tool  Tip:  Process  Mapping 

Description 

•  representation  of  major  activities/tasks,  subprocesses, 
process  boundaries,  key  process  inputs,  and  outputs 


INPUTS 

(Sources  of 
Variation) 

•  People 

•  Material 

•  Equipment 

•  Policies 

•  Procedures 

•  Methods 

•  Environment 

•  Information 


OUTPUTS 

PROCESS  STEP 

(Measures  of 

A  blending  of 

Performance) 

inputs  to  achieve 

•  Perform  a  service 

the  desired 

•  Produce  a  Product 

outputs 

•  Complete  a  Task 
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Mapping:  Usage 

Feeds  other  tools  (OID,  OPP,  CAR) 

•  Cause  and  Effects  Matrix 

•  Failure  Modes  and  Effects  Analysis  (FMEA) 

•  Control  Plan  Summary 

•  DOE  planning 

Tips  for  mapping  current  processes  (OPP) 

•  Go  to  the  actual  place  where  the  process  is  performed. 

•  Talk  to  the  actual  people  involved  in  the  process  and  get  the 
real  facts. 

•  Observe  and  chart  the  actual  process. 

•  Consider  creating  “as  is”  and  then  “to  be”  maps. 

Reality  is  invariably  different  from  perception  -  few 
processes  work  the  way  we  think  they  do! 
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Mapping:  Terms 

Controllable  Inputs:  Key  Process  Input  Variables  (KPIVs)  that 
can  be  changed  to  see  the  effect  on  Key  Process  Output 
Variables  (KPOVs).  Sometimes  called  “Knob”  Variables. 

Critical  Inputs:  KPIV  s  that  have  been  statistically  shown  to 
have  a  major  impact  on  the  variability  of  the  KPOVs. 

Noise  Inputs:  Input  variables  that  impact  the  KPOVs  but  are 
difficult  or  impossible  to  control.  Example:  Environmental 
variables  such  as  humidity,  ambient  temperature,  etc. 

Standard  Operating  Procedures:  A  standard  procedure  for 
running  the  process. 
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Mapping:  Example 

Inspection  process  from  earlier  illustration 


Plan 


Detect 

Defects 


Trouble¬ 

shoot 


Correct 

_ 

Defects 

O  Artifacts  to 
inspect 

#,  *  Artifact  size 

•  Reviewers 

*  Data  repository 


O  Review  Rate 
O  ,  *  Checklists 
#,  *  Inspection 
method,  procedure 
*  Proficiency 
f  Taxonomy 
interpretations 


What  would 
you  list? 


What  would 
you  list? 


Defect  Log  •  Direct  Cause  •  Corrective 
Record  of  plan  •  Root  Cause  Action 


( - 

A 

Inspection 

O 

Critical  Inputs 

> 

*  Standard  Procedure 

O 

v _ 

Rework 

t 

Noise 

•  Control  Knobs 

_ y 
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Mapping  Variation:  Value  Map 

Identify  the  process  to  map. 

Identify  the  boundaries. 

Create  input-process-output  for  the  critical  processes. 

Create  the  process  map. 

Color  code  each  step  identifying  value. 

•  green  =  value  added 

•  red  =  non  value  added 

•  yellow  =  non  value  added  but  necessary 

Identify  hand-off  points,  queues,  storage,  and  rework  loops  in  the 
process. 

Quantitatively  measure  the  map  (throughput,  cycle  time,  and 
cost). 

Validate  map  with  process  owners. 
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Value  Mapping 


initial  Assessment  will: 

•  Determine  Impact  Assessment 

•  Identify  Stakeholder 

•  Coordinate  with  Product/Process  Owner 

•  Perform  Impact  Analysis 
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Process  Map  Practice 

Complete  the  inspection  process  map  presented  in  this 
“tool  tip.” 

Or,  create  a  new  inspection  process  map  based  on  your 
experience. 


Note:  This  and  the  next  slide  are  provided  for  post-tutorial  process  mapping  practice. 
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Your  Process  Map  Here 
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Tool  Tip:  7  Basic  Tools 

Description 

•  Fundamental  data  plotting  and  diagramming  tools 

-  Cause  &  Effect  Diagram 

-  Histogram 

-  Scatter  Plot 

-  Run  Chart 

-  Flow  Chart 

-  Brainstorming 

-  Pareto  Chart 

•  The  list  varies  with  source.  Alternatives  include 

-  Statistical  Process  Control  Charts 

-  Descriptive  Statistics  (mean,  median  and  so  on) 

-  Check  Sheets 
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7  Basic  Tools:  Usage 

PLOT,  PLOT,  PLOT! 

•  use  these  tools  to  describe  the  process 

•  expand  and  extend  the  charts  as  needed 

Used  throughout  Six  Sigma  projects  and  within  many 
other  tools: 

•  MBF 

•  troubleshooting  as  a  result  of  “out  of  control”  point 
Many  accomplishments  are  built  on  these  tools  alone. 
Handy  resource:  “The  Memory  Jogger” 


[Memory  Jogger:  http://www.goalqpc.com] 
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7  Basic  Tools:  Chart  Examples 


90 
80 
70  - 
^60 
£50 
§40 
0  30 
20 
10 
0 


Defects  Removed  By  Type 


Pareto  Chart 


40  80  50  10 

Defect  Type  Codes 


Run  Chart 


Mean  Time  To  Repair 


1  23456789  10 

Product 
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7  Basic  Tools:  Cause  &  Effect 
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7  Basic  Tools:  Chart  Variations 


Box  &  Whisker  Plot 
for  assessment  data 


mean 


90th  percentile 
75th  percentile 
median:  50th  percentile 
25th  percentile 
10th  percentile 


CMMI  BENCHMARK 
SEI  Level  3 
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7  Basic  Tools:  Chart  Variations 

Boxplot  variations: 

•  cost  and  schedule  variance  over  time  to  show 
organizational  average  and  also  variability 

•  prioritized  features  for  a  new  process  technology  rollout: 
a  combination  “pareto-boxplot” 


potential  (specific)  process  features 
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Tool  Tip:  Lean 

“An  organization  working  together  to  make 
continuous  improvements  without  large 

capital  investment” 


Purpose 

•  brings  the  right  people  together  to  understand  the 
process  and  make  immediate  improvements  to  the 
process. 

•  evaluates  opportunities  to  reduce  cycle  time,  cost, 
inventory  and  eliminate  all  waste. 
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Lean:  Terms  &  Usage 


Kaizen  -  Make  people’s  jobs  easier  by  taking  them  apart, 
studying  them,  and  making  improvements. 

•  “KAI”  -  take  apart  and  make  anew 

•  “ZEN”  -  think,  make  good  the  actions  of  others,  do  good 
deeds  and  help  others 

Kaizen  tips  (VAL,  M&A,  QPM,  CAR,  OPP) 

•  Get  rid  of  old  assumptions. 

•  Look  for  ways  to  make  things  happen  now. 

•  Say  “NO”  to  the  status  quo. 

•  Don’t  worry  about  being  perfect. 

•  It  doesn’t  have  to  cost  money. 

•  If  something’s  wrong,  fix  it  on  the  spot. 

•  Ask  “WHY”  five  times  to  get  to  the  root  cause. 

•  Look  for  wisdom  from  many  people  rather  than  one. 

•  Never  stop  improving. 

•  Full-time  participation  of  team  members. 

•  Keep  all  affected  employees  informed  of  changes. 
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Lean:  Six  Sigma  Representation 


©  2003  by  Carnegie  Mellon  University 


page  83 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


Lean:  Kaizen  Procedure 

Top  Mgmt  Kick-off  of  event 

Determine  Team  Objectives  and  Goals 

Lean/Six  Sigma  Training 

Map  as-is  Process 

Identify  Waste  in  the  process 

Use  root  cause  analysis  to  evaluate  issues 

Brainstorm  solutions 

Evaluate  the  solutions  against  the  objectives 
Report  to  Sponsor 

Implement  validated  solutions  to  improve  the  process 
Standardize:  Map  the  to-be  /  improved  process 
Report  to  Sponsor 


©  2003  by  Carnegie  Mellon  University 


page  84 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


Lean:  Staffing  Analysis  Example  ■, 

“As  Is”  Logical  Process  Map 
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Lean:  Staffing  Analysis  Example  2 


“To  be”  Logical  Process  Map 


◄ 


©  2003  by  Carnegie  Mellon  University 


Self-Serve 


Finance  — 
Generated 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN % 


Lean:  Staffing  Analysis  Example  3 


Time  Value  Map: 
As  Is  =  19  hours 


Legend 
R  =  Request 
Q  =  Query 
S  =  Select  data 
T  =  Test  Report 
A  =  Analysis 
F  =  Format 
P  =  Pivot  table 
D  =  Deliver 
*  =  Variable  wait  time 


25%  rework 


Time  Value  Map: 
To  Be  =  7  hours 


R  Q  S 

T  A  F  P  D 

15 

1C 

15 

* 

!5 

1C 

15 

20 

1 

* 

Q  S  R 


20 


63% 
reduction 
in  cycle 
time 


3%  rework 
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Additional  Analytical  Tools 


Quality  Function  Deployment  (RM,  RD) 

•  designs  what  customers  REALLY  want 

•  prevents  designing  unnecessary  product  features 

Bayesian  Modeling  (VER,  VAL,  PI) 

•  alternative  to  classical  regression-based  models 

•  accounts  for  prior  knowledge  and  likelihood 

•  network  diagrams  show  cause  &  effect  relationships 

Systems  Thinking  (TS,  DAR,  M&A,  QPM,  OPP) 

•  for  chronic,  describable,  important  problems  with 
previous  unsuccessful  attempts  to  solve 

•  several  tools  to  map  and  understand  process 

See  Addendum  for  additional  information  about  selected  tools. 
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LMC  M&DS  Lessons  Learned 

Six  Sigma  is  more  than  statistical  analysis 

•  It  is  a  tool  box  of  methodologies  that  align  with  an 
organization's  process  improvement. 

•  The  alignment  is  directly  related  to  high  maturity  but  is 
not  restricted  to  that. 
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Outline 

Objectives 
Fundamentals 
Implementation 
The  “Black  Belt”  Project 

Case  Study 

Summary 
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Applications 

Six  Sigma  applications  for 

Systems  and  Software  Engineering  are 

emerging. 
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Survey  of  Applications  1 

Motorola 

•  inspection  data  analysis  &  unit  test  optimization 

•  risk-based  software  inspections 

•  design  of  experiments  methods  &  test  cases 

•  complexity  analysis  &  resource  allocations 

•  quantitative  risk  management  via  uncertainty  modeling 

General  Electric 

•  DFSS 

•  Six  Sigma  &  Extreme  Programming 
Allied  Signal 

•  1997  air  supply  control  system  shutdowns 

•  black  belt  project  team  commissioned  to  find  solution 


[Harry  00],  [Stoddard  00],  [Kelliher  01] 

Motorola  &  GE  presentations  available  at  http://seir.sei.cmu.edu 
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Survey  of  Applications  2 

Honeywell 

.  pspsm/tspsm  &  Six  Sjgma 

-  “TSP  provides  the  data  needed  to  apply  Six  Sigma” 

JP  Morgan 

•  Capability  Maturity  Model®  (CMM®)  &  Six  Sigma 

-  “...Six  Sigma  methodology  is  beneficial  on  all  levels  of 
maturity.” 

NCR 

•  CMM  &  Six  Sigma 

-  “...helps  organizations  working  towards  Level  4  &  5 
deliver  the  best  business  results.” 

[Pavlik  00],  [A-M  99],  [Demery  01] 

Presentations  available  at  http://seir.sei.cmu.edu 
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LMC  M&DS  -  Strategy 

Analyzed  Principles 

•  Value  from  the  customers'  perspective 

•  Value  Stream  -  measured 

•  Flow 

•  Pull 

•  Perfection  -  rapid  feedback  /  mistake  proofing 

World-wide  Benchmarking  Results 

•  A  4  Sigma  company  will  spend  >  1 0%  of  revenue  on 
internal  and  external  repair. 

•  A  6  Sigma  company  will  spend  <  1  %  of  revenue  on 
internal  and  external  repair. 
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LMC  M&DS  Project  Selection 

1.  Process  Improvement  Recommendation  (PIR) 

any  one  can  submit 

process  suggestion  passed  to  Process  Owner  to  evaluate, 
determine  feasibility,  determine  level  of  institutionalization 
(and  determine  if  pilot  is  necessary) 

2.  E-Transformation 

all  business  processes  that  affect  overhead  are  applicable 
selection  based  on  ROI  and  relevance  to  business  -  firm 
understanding  of  the  before  state 

-  Just  do  it  Projects 

-  Kaizen  event  with  rollout  plan 

require  use  of  Six  Sigma  methodologies/  tools  to  pursue 
optimization 

3.  Technology  Change  Management  Working  Group  (TCMWG) 

once  a  year  call  for  ideas  -  process  oriented 
can  also  be  used  to  pilot  ideas  from  PIRs 
selection  based  on  understanding  the  before  state  to 
measure  the  after  state 

modeling  techniques  implementing  a  six  sigma  target 
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LMC  M&DS  Technology  Change 
Management  1 


Purpose  (M&A,  RSKM,  TS,  QPM,  OPP,  OID) 

•  identify  and  assess  emerging  process-related  technologies 
(e.g.,  Tools,  Commercial  Practices) 

•  guide  those  having  benefit  into  our  development  activities  in 
an  orderly  manner 

Implementation  (OID) 

•  Technology  Change  Management  (TCM)  Working  Group 
(TCMWG)  formed  to  identify  process  improvement  needs  and 
oversee  the  planning,  progress,  and  application  of  solutions 

•  each  functional  organization  represented  on  TCMWG 

•  annual  call  for  TCM  project  proposals 

-  parallel  effort  with  call  for  I  RAD  projects 

-  based  on  needs  expressed  in  the  strategic  plan 

•  meets  monthly  to  review  ongoing  projects,  assess  new 
business  needs,  and  communicate  new  technology 


©  2003  by  Carnegie  Mellon  University 


page  96 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTI  A 


LMC  M&DS  Technology  Change 
Management  2 


Definition 

•  process-centric  (as  opposed  to  product-centric) 

•  separation  of  former  and  latter  based  on  legal  barriers 

•  Technology  changes  for  product  is  accomplished  by  extensive 
I  RAD  effort 

•  enterprise  wide 

Focus  on  TCM  motivated  by  Acquisition  Reform  in  1995 

•  considerable  maturing  of  TCM  process  in  six  years 

•  business  results  rather  than  just  “ticket  punching” 

•  utilizes  value  added  methodology  -  6  Sigma  Tools 

Driven  by  LMC  M&DS  Strategic  Plan 

•  TCM  participants  contribute  to  Strategic  Plan 

Harmonious  with  company-wide  process  philosophy 
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LMC  M&DS  Technology  Development 
Programs:  There  are  Two! 


Focus: 

Product  Technoloav 

Process  Technoloav 

Develop  For: 

What  you  sell 

How  you  do  your  work 

Catalyst: 

Continued  rapid  advances  in  IS 
enabling  technologies,  e.g., 
microelectronic  devices,  fiber  optics, 
and  wireless  communications 

Acquisition  Reform 

Funding: 

NBAE/IR&D 

OH/Indirect  $ 

Sponsor: 

IR&D  Program 

TCM  Program 

Each  program  develops  technology  discriminators 
and  enhances  our  win  probabilities 
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TCMWG  Organization  and  Operations 


Proposal 

Selection 

Committee 


Steering 

Committee 


a 


Review 
LMC  M&DSI 
Business 
Needs 


Establish 

Priority 

Process 

Improvement 

Needs 


Approve 

Gain 

Projects/ 

EPSC 

Identify  & 

— > 

Approval 

Obtain  Funds 

for  TCM 

Plan 

Review 

Project 

Status 

Quarterly 


Solicit  Ongoing 
Business/Functional 
Specific  Initiatives 

A 


Project 

Review  Project 

Oversight 

Status,  Assign 

Committee 

Actions 
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TCM  Proposal  Results 


Representation 

•  All  LMC  M&DS  regions  represented  on  the  selection 
team. 

•  All  LMC  M&DS  regions  had  proposals  submitted. 
Quality  of  proposals  -  good 

Quantity  of  proposals  managed  (typical  year) 

•  51  proposals  received 

•  23  proposals  ranked 

•  12  proposals  identified  and  ranked  for  the  TCM 
Program  Plan. 

Proposed  budget  for  TCM  Program  Plan 
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Focus,  Focus,  Focus 

Goal  -  shift  defect  detection  curve  to  find  more  defects  earlier  in  the  life 
cycle 

Focused  Technology  Change 

•  Incorporates  both  new  processes  in  utilizing  goal  into  the  existing 
process 

•  Integrates  new  tools  into  the  inspection  process  and  defect  tracking 
measurements 

Before  State 

•  Defect  curve  shows  later  defects  -  14  defects/KSLOC  during  test 
phase 

After  State 

•  Decrease  in  test  defects  because  found  earlier  in  process 

•  Goal  X  defects/KSLOC  during  test  phase 

•  Pilot  actually  beat  the  goal 


teohopJ og yntihread  to  address 
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TCM  Flow  Example 


RATIONALE  DEVELOP  APPROACH  MEASURE  /MANAGE/  REFINE 
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Process  Change  -  Common  Inspection  Process 


Focused  Process  Change 

•  Institutionalization  of  one  inspection  process  method 

•  Single  process  for  inspections  on  all  programs  in  all  phases 

Before  State  -  Walkthrus 

•  X  Defects  /  KSLOC  during  Detailed  Design 

•  X  Defects  /  KSLOC  during  Code  &  Unit  Test 

After  State  -  Inspections 

•  X  Defects  /  KSLOC  during  Detailed  Design 

•  X  Defects  /  KSLOC  during  Code  &  Unit  Test 


One  process  thread  to  address 

©  2003  by  Carnegie  Mellon  University  page  1 03 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


Process  Change  Flow 


©  2003  by  Carnegie  Mellon  University 


page  104 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTI  A 


LMC  M&DS  TCM  Summary 


The  TCM  Program  is  driven  by  the  strategic  process 
needs  of  our  product  lines. 

TCM  projects  have  had  a  positive  impact  on  new  business 
pursuits. 

TCM  projects  have  resulted  in  cost  savings  as  well  as  cost 
avoidance. 

TCM  projects  can  result  in  changes  to  the  standard 
processes. 

Our  business  leaders  are  encouraged  to  push  process 
boundaries  through  TCM. 
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What  are  your  “take-away”  learnings? 

What  is  immediately  useful  in  your  workplace? 
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Outline 

Objectives 

Fundamentals 

Implementation 

The  “Black  Belt”  Project 

Case  Study 

Summary 
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Key  Points 


Six  Sigma  is  about  customer  satisfaction  and  business 
profitability. 

Software  and  systems  engineering  organizations  are  using  Six 
Sigma. 

•  They  are  effectively  blending  it  with  their  overall  set  of 
processes,  models,  standards. 

•  Each  “blend”  is  based  on  organizational  context  (sorry,  no 
“silver  bullet”). 

•  They  are  applying  it  to  projects,  programs,  products,  and 
engineering  processes. 

The  analytical  toolkit  contains  familiar  and  new,  extended  tools. 

•  They  are  applicable  to  software  and  systems  engineering. 

•  Some  are  “statistical”  and  some  are  “analytical.” 

The  industry  needs  a  comprehensive  set  of  case  studies  of  Six 
Sigma  in  SW/SE  (similar  to  what  is  available  in  manufacturing). 
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Advancing  the  State  of  60  &  SW/SE 

Discussion  Group 

•  http://qroups.vahoo.com/qroup/6S  SWSE 

•  current  issues,  most  recent  works 

Repository  of  Examples  &  Benefits 

•  http://seir.sei.cmu.edu 

•  concrete  visualization 

•  relationship  to  models,  initiatives 

•  variety  of  analytical  methods 

•  multiple  perspectives 

-project,  process,  product 
-software,  systems 
-maturity/capability  levels 
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Advancing  the  State:  Publishing 

Call  for  papers:  Software  Quality  Professional 

•  Seeking  practical,  experience-based  articles 

-  case  studies 

-  solutions/improvements  to  critical  process,  products 

-  training  issues,  multi-initiative  usage 

Call  for  reviewers 

•  Green,  Black  or  Master  Black  Belts 

Contact  imsiviv@sei.cmu.edu 
if  you  would  like  to  participate 
or  want  more  information 
(flyers  available  post-tutorial) 
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Advancing  the  State: 

Birds  of  a  Feather  Session 


Wednesday  evening 

Proposed  agenda 

•  10  minute  “what’s  new” 

•  discussions: 

-  Six  Sigma  basics  (for  newbies) 

-  comparisons  of  different  approaches  to  integrating 
intiatives 

-  tailoring  training  for  software  and  systems  engineers 

-  lessons  learned  from  the  field 

Signup  sheet  posted  in  registration  area 
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Summary 


Customer  satisfaction  is  key  driver 
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Contact  Information 

M.  Lynn  Penn 

Lockheed  Martin  Management  &  Data  Systems 

P.O.  Box  8048 

Building  A,  Room  25A17 

Philadelphia,  PA  19101 

Email:  marv.lvnn.Denn@lmco.com 

610-354-1188 

Jeannine  Siviy 

Software  Engineering  Institute 
Measurement  &  Analysis  Initiative 
Email:  imsiviv@sei.cmu.edu 
412-268-7994 
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Additional  Reading  1 

Six  Sigma  Books  (not  software-specific): 
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Pyzdek,  Thomas,  The  Six  Sigma  Handbook,  McGraw-Hill  Professional  Publishing,  2001 
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Six  Sigma  Academy,  http://www.6-siqma.com 
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Software  Engineering  Information  Repository:  http://seir.sei.cmu.edu  (Follow  links  to  Measurement 
area  then  to  Six  Sigma) 

SEI  Software  Technology  Review:  http://www.sei.cmu.edu/str/descriptions/siqma6.html 
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Additional  Reading  2 

Papers,  presentations,  journal  articles  (URL’s  subject  to  change  without  notice) 

6  Sigma  Pro,  Quality  Digest,  May  2000,  http://www.qualitvdiqest.com/mavOO/html/sixsiqmapro.htmi 

6  Sigma  Con,  Quality  Digest,  May  2000,  http://www.qualitvdiqest.com/mavOO/html/sixsiqmacon.html 

Arnold,  Paul  V.,  Pursuing  the  Holy  Grail,  MRO  Today,  June/July  1999, 
http://www.mrotoday.com/mro/archives/Editorials/editJJ1999.htm 

Biakeslee,  Jerome  A.,  Jr.,  Implementing  the  Six  Sigma  Solution,  Quality  Progress,  July  1999 

Bramble,  Larry,  Lessons  Learned  from  Merging  Six  Sigma  and  the  CMM,  European  SEPG  2002 

Card,  David,  Sorting  out  Six  Sigma  and  the  CMM,  IEEE  Software,  May/June  2000 

Card,  David,  Integrating  Six  Sigma  and  the  CMMI,  Software  Technology  Conference,  29  April  -  2  May 
2002 

Dusharme,  Dirk,  Six  Sigma  Survey:  Breaking  Through  the  Six  Sigma  Hype,  Quality  Digest,  November 
2001 ,  http://www.qualitvdiqest.com/nov01/html/sixsiqmaarticle.html 

Harrington,  H.  James,  Six  Sigma  for  Internet  Application  Development,  available  at 
http://www.stickyminds.com  and  at  http://qroups.yahoo.com/qroup/6S  SWSE 

Hammer,  Michael,  Process  Management  and  the  Future  of  Six  Sigma,  MIT  Sloan  Management  Review, 
Winter  2002 
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Additional  Reading  3 

More  papers,  presentations,  journal  articles  (URL’s  subject  to  change  without  notice) 

Harrold,  Dave,  Optimize  Existing  Processes  to  Achieve  Six  Sigma  Capability,  Control  Engineering 
Online,  March  1999,  http://www.controlenq.com/archives/1999/ctl0301 .99/03a301  .html 

Keller,  Paul,  Recent  Trends  in  Six  Sigma,  ASQ  Annual  Quality  Conference,  April  2001 

Lahiri,  Jaideep,  The  Enigma  of  Six  Sigma,  The  Net  Business  of  the  India  Today  Group, 
http://www.india-todav.com/btodav/19990922/cover.html 

Northrop  Grumman’s  Six  Sigma  Roadmap,  ASQ  Six  Sigma  Forum, 

http://www.sixsiqmaforum.com/protected/articles/bb/bb  ss  aerospace  l.shtml  (membership  required) 

Pavlik,  Rich  and  Cary  Rial!,  Integration  PSPSM,  TSPSM,  and  Six  Sigma  Plus  at  Honeywell,  Honeywell 
Air  Transport,  SEPG  2002 

Paul,  Lauren  Gibbons,  "Practice  Makes  Perfect,"  CIO  Enterprise  Magazine,  15  January  1999, 
http://www.cio.com/archive/enterprise/01 1599  process.html 

Pyzdek,  Thomas,  Why  Six  Sigma  is  Not  TQM,  Quality  Digest,  February  2001 , 
http://www.qualitvdiqest.com/feb01/html/sixsiqma.html 

Pyzdek,  Thomas,  Ignore  Six  Sigma  at  Your  Peril,  Quality  Digest,  April  2001 , 
http://www.qualitvdiqest.com/april01/html/sixsiqma.html 

Smith,  Bonnie  and  Emily  Adams,  LeanSigmaSM:  Advanced  Quality,  ASQ  Annual  Quality  Conference, 
April  2001 

Smith,  Larry  R.,  Six  Sigma  and  the  Evolution  of  Quality  in  Product  Development,  Six  Sigma  Forum 
Magazine,  November  2001 

Young,  Tim,  Merging  Six  Sigma  and  IT,  Six  Sigma  Forum  Magazine,  February  2002 
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Additional  Reading  4 

References  on  statistics  and  analytical  tools  (URL’s  subject  to  change  without  notice) 

General  Statistics 

Davis,  Wallace  III,  Using  Corrective  Action  to  Make  Matters  Worse,  Quality  Progress,  October  2000 
Gonick,  Larry  and  Smith,  Woollcott,  The  Cartoon  Guide  to  Statistics,  HarperPerennial,1993 
Wheeler,  Donald,  J.  Understanding  Variation  -  The  Key  to  Managing  Chaos,  SPC  Press,  1993 

Statistical  Process  Control 

AT&T  /Western  Electric  Co.,  Statistical  Quality  Control  Handbook,  Delmar  Printing  Company 
Chrysler,  Ford,  General  Motors  Corp.,  Statistical  Process  Control  -  SPC,  A.I.A.G.  1995 
Florae,  William  A.,  and  Anita  D.  Carleton,  Measuring  the  Software  Process,  Addison-Wesley,  1999 
Wheeler,  Donald,  and  David  S.  Chambers,  Understanding  Statistical  Process  Control,  SPC  Press,  1992 

Lean  Thinkinq/Business  Strategies: 

Goldratt,  Eliyahu  M.  The  Goal,  North  River  Press,  1992 

Dettmer,  William,  Goldratt’s  Theory  of  Contraints:  A  Systems  Approach  to  Continuous  Improvement, 
American  Society  for  Quality,  1997 

Bayesian  Modeling: 

Fenton,  Norman  and  Martin  Neil,  Software  Metrics:  Roadmap,  International  Conference  on  Software 
Engineering,  2000,  available  at  http://www.softwaresvstems.org/future.html 
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Tool  Tip:  Cause  &  Effect  Matrix 

Description 

•  method  to  determine  possible  causes  of  variation  in  the 
process  and  to  feed  future  experimental  designs 

Purpose 

•  to  organize  problem-solving  efforts  when  there  are 
multiple  responses  involved 

•  to  prioritize  the  number  of  factors  to  study 

•  to  build  team  consensus  about  what  is  to  be  studied 


[Hexsab  02] 
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Cause  &  Effect  Matrix:  Usage 

When  to  use: 

•  team  is  overwhelmed  with  the  number  of  variables  affecting 
process 

•  not  possible  to  experiment  with  all  of  the  variables  -  need  to 
narrow  down  the  list 

•  team  is  struggling  with  which  factors  may  have  the  biggest 
impact 

•  it  is  not  clear  how  each  factor  impacts  customer  requirements 
Feeds  other  tools: 

•  Failure  Mode  and  Effects  Analysis 

•  Data  collection  plans 

•  Experimentation 

•  Control  plans 

[Hexsab  02] 
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Cause  &  Effect  Matrix:  Terms 


Process:  The  combination  of  people,  equipment,  materials,  methods 
and  environment  that  produce  output  (product  or  service).  It  is  a 
repeatable  sequence  of  activities  with  measurable  inputs  and  outputs. 

Parameter:  A  measurable  characteristic  of  a  product  or  process. 

Process  Parameter:  A  measurable  characteristic  of  a  process  that  may 
impact  product  performance  but  may  not  be  measured  on  the  product. 
(The  “x.”) 

End-Product  Parameter:  A  parameter  that  characterizes  the  product  at 
the  finished  product  stage.  (The  “Big  Y.”) 

In-Process  Product  Parameter:  A  parameter  that  characterizes  the 
product  prior  to  the  finished  product  stage.  It  is  measured  on  the  product 
upstream  and  is  the  result  of  a  process  step.  (The  “little  y.”) 

Input  Variable:  An  output  from  other  processes.  (Neither  x’s  or  y’s.) 
[Hexsab  02] 
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Cause  &  Effect  Matrix:  Procedure 


Identify  the  y’s  from  process  map. 

Rate  the  y’s  on  a  scale  from  1-10. 

•  Involve  the  “customers”  to  determine  the  ratings. 

•  Ratings  are  relative. 

List  the  process  steps  and  all  of  the  x’s  from  the  process  map. 

Rate  the  relationship  of  each  x  to  each  y  on  a  0,  1 , 3,  9  scale. 

0  =  No  relationship  between  x  and  y 
1  =  Remote  relationship  between  x  and  y 
3  =  Moderate  relationship  between  x  and  y 
9  =  Strong  relationship  between  x  and  y 

For  each  x 

•  Multiply  each  relationship  rating  by  the  corresponding  y  rating 

•  Sum  the  products 

Use  the  summations  to  rank  and  select  x’s  for  future  experiments  or 
focused  efforts 

[Hexsab  02] 
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Cause  &  Effect  Matrix:  Format 


Y's: 

Y  ratings: 

Process  steps 

X's 

X  relationship  to  Y 

Sum 

[Hexsab  02] 
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Tool  Tip:  Quality  Function 
Deployment  (QFD) 


Description 

•  a  structured  methodology  used  to  identify  customers' 
requirements  and  translate  them  into  key  process 
deliverables 

•  helps  you  focus  on  ways  to  improve  your  process  or 
product  to  meet  customers'  expectations 

•  systematically  translates  and  prioritizes  customer-level 
CTQ's  into  clear,  quantifiable  design  objectives 


[isixsigma],  [harrold  99-2] 
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QFD:  Usage 


Benefits 

•  Designs  what  customers  REALLY  want 

•  Prevents  designing  unnecessary  product  features 

•  Aligns  business  unit  and  engineering  tactics  &  goals 

-  a  series  of  QFD  matrices  can  link  CTQ's  of  product 
specifications  with  product  design  with  process 
design  with  process  control* 

•  Defines  and  sets  realistic  product  specifications 

•  Optimizes  product  and  process  costs 

•  Reduces  post-introduction  problems  and  surprises 

•  Gives  quicker  starts  on  next  product  generation(s) 


*[brecker.com] 
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Quality  Function  Deployment 


Start  of  Start  of 

development  production 

cycle 


Source:  L.P.  Sullivan,  “Quality  Function  Deployment,”  Quality  Progress,  June  1986,  p.  39 
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QFD: 


WHAT 


House  of  Quality 

HOW 


x 

Product 

Technical 

Requirements  (PTR’s) 

1  1  V\ 

1 1  III  II  1  1  1  III  1  III  1  III 

Customer 

Needs 

Relationship  Matrix 

T“T~I  T“1  r~ 

Target  Values 

Technical  Benchmarking 

Subjective 

Competitive 

Evaluation 


WHY 


Importance  Weighting 
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Tool  Tip:  Systems  Thinking 

Description 

A  discipline  for  seeing  interrelationships,  patterns  and 
wholes 

Event  driven  thinking: 

•  Put  out  the  fire. 

Statistical  thinking: 

•  Based  on  history  and  likelihood  of  fires,  where  should 
fire  prevention  equipment  be  concentrated? 

Systems  thinking: 

•  How  can  the  fires  be  avoided? 
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Systems  Thinking 

Theory  of  constraints  (TOC) 

•  prerequisite  trees 

•  current  reality  trees 

•  future  reality  trees 

•  transition  trees 

•  conflict  resolution  diagrams 

Causal  loop  diagrams 
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Systems  Thinking:  Senge’s  laws 


•  Today’s  problems  come  from  yesterday’s  solutions. 

•  The  harder  you  push,  the  harder  the  system  pushes  back. 

•  Behavior  grows  better  before  it  grows  worse. 

•  The  easy  way  out  usually  leads  back  in. 

•  The  cure  can  be  worse  than  the  disease. 

•  Faster  is  slower. 

•  You  can  have  your  cake  and  eat  it  too  -  but  not  at  once. 

•  Dividing  the  elephant  in  half  does  not  produce  two  small 
elephants. 

•  There  is  no  blame. 

•  Cause  and  effect  are  not  closely  related  in  time  and  space. 

•  Small  changes  can  produce  big  results  -  but  the  areas  of 
highest  leverage  are  often  the  least  obvious. 
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Systems  Thinking:  Dettmer’s  TOC 
Principles 


•  Systems  are  analogous  to  chains  -  having  a  weakest 
link  or  constraint. 

•  Strengthening  anything  but  the  weakest  link  does  not 
strengthen  the  chain. 

•  The  system  optimum  is  not  the  sum  of  the  local  optima. 

•  Systems  operate  in  a  complex  cause  and  effect 
environment. 

•  Most  undesirable  effects  are  due  to  a  few  core 
problems. 

•  Core  problems  are  almost  never  superficially  apparent. 

•  System  constraints  can  be  physical  or  policy. 

•  Optimal  solutions  deteriorate  over  time  as  the 
environment  changes. 

•  Ideas  are  not  solutions. 
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Tool  Tip:  Statistical  Process  Control 


Description: 

•  run  chart  with  statistical  limits 

•  distinguishes  common  cause 
cause  variation  and  identifies 
taken  to  correct  a  process 


variation  from  special 
when  actions  need  to  be 
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SPC:  Terms 


Common  cause  variation:  the  variation  which  is  inherent  to  the  process 
as  it  normally  occurs 

Special  (or  “assignable”)  cause  variation:  variation  which  is  unusual 
and  indicative  of  a  change  in  the  process. 

In  control:  stable,  random,  predictable;  only  common  cause  variation 
present. 

Out  of  control:  unstable,  shifting  data  with  trends  or  patterns;  special 
cause  variation  present 

Corrective  Action  Guidelines  (CAGs):  the  rules  to  follow  when 
assignable  causes  are  present;  When  causes  are  not  well-understood, 
then  CAG  may  be  an  analytical  troubleshooting  guide  (i.e.,  how  to 
drilldown  through  the  data  and  rule  things  out) 
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SPC:  Tips 

Reacting  to  Common  Cause  Variation  as  if  it  were  Special 
Cause  Variation  cannot  improve  the  process  and  will 
result  in  increased  variability. 

Check  your  data  distributions! 

•  Defect  counts  are  never  negative  and  may  not  be 
normally  distributed. 

Set  control  limits  based  on  statistics,  engineering 
knowledge  and  risk  of  escaping  defects. 
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Addendum 

Additional  reading 

Additional  analytical  tools:  abbreviated  “tool  tips” 

Additional  illustration 

Change  Agent  References 
CMMI  Process  Areas 


©  2003  by  Carnegie  Mellon  University 


page  140 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


Illustration  -  “Define”  i 

Business  Driver 

•  Need  10%  cost  reduction  in  order  to  compete  in  the 
marketplace  and  stay  in  business 

Baseline  data  (PSP) 

•  Productivity:  19  LOC/hr 

•  33%  of  development  time  spent  fixing  defects 

•  Approximately  250  defects/KLOC 
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Illustration  -  “Define”  2 

Goal: 

•  Reduce  or  prevent  defects  to  reduce  cost 

Quantitatively  speaking: 

•  Reduce  cycle  time  by  22  minutes/program 

•  Reduce  fix  time  by  1 .3  minutes/defect 

•  Reduce  defects  by  6/program 

•  Reduce  defect  density  to  1 90  defects/LOC 

...  or  a  combination  that  produces  21  LOC/hr 
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Illustration  -  “Analyze” 

Opportunities  to  reduce  repair  time 

•  Defects  removed  in  test:  78%  of  repair  time 

•  Defects  injected  in  design:  25%  of  repair  time 

•  Defects  injected  in  code:  56%  of  repair  time 

•  Syntax  defects  in  general:  63%  of  defects 


Injected  Defects  Fix  Time, 
Baseline  programs  1-6 
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Illustration  -  “Improve” 


Improvement  Plan  at  Program  6 

•  Syntax  checklist 

•  Well-timed  reviews 

•  Subcategories  within  defect  types 
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Illustration  -  “Control” 

Tracking  performance 

•  Quantitative  goal  statement 

•  Hypothesized  root  causes 

•  Countermeasures  &  contribution  to  impact 

•  Key  impact  indicators 


Direct  causes  (from  countermeasures): 

•  Fewer  defects  injected  in  code  &  test 
•Defects  removed  earlier,  faster  (i.e.,  in 
design  &  code) 

Root  cause  (need  new  countermeasures): 

•“Re-learning”  curve 
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Illustration  -  Analysis  Summary 

Tools  used  in  full  analysis  included 

•  Process  Mapping 

•  Descriptive  statistics 

•  Means  comparisons  &  significance  testing 

•  Plots 

-  Pie  Charts 

-  Trends 

-  Phase  profiles 

-  Histograms 

-  Pareto  charts 

-  Correlation  plots 

•  Cause  &  Effect  Diagrams 

•  “Management  by  Fact” 

Focus  was  exploratory,  investigative 

•  Ready  for  stability  &  control  monitoring 
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Illustration  -  Scaling  up 


Illustration 

■  Quickly  drilled  down  from 
high  level  cost  goal  to 
personal  improvement 

■  Defined  process  in  place 

■  Measures  in  place 

■  Continuous  incremental 
improvements 

■  Event-based  “step- 
change”  mprovements 

■  Re-learning  curve 

■  Personal  data 

■  Used  productivity  as  one 
of  impact  measures 
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Real  Life 

■  Drill  down  may  be  complex, 
may  span  wide  breadth  of 
organization 

■  May  need  to  select  or  define 
process 

■  May  need  to  develop  measures 

■  Continuous  incremental 
improvements 

■  Event-based  “step-change” 
improvements 

■  Constantly  changing  skills, 
technologies 

■  Non-attributed  data  (e.g.,  team, 
project) 

■  Excessive  productivity  focus 
may  drive  unwanted  behaviors 
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Addendum 

Additional  reading 

Additional  analytical  tools:  abbreviated  “tool  tips” 
Additional  illustration 

Change  Agent  References 

CMMI  Process  Areas 
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How  Organizations  Commit  to 
Change 


from  Daryl  R.  Conner  and  Robert  W.  Patterson.  “Building  Commitment  to  Organizational  Change,”  Training  and 
Development  Journal  (April  1983):18-30. 
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A  Formulaic  Approach  to  Change 

D  x  y  x  f  >  R 

till 

Dissatisfaction  Vision  of  First  Resistance  to 

with  the  present  the  Future  Steps  Change 


“All  elements  of  the  formula  must  be  present  or  resistance  to 
the  change  will  not  be  overcome.” 

Richard  Beckhard 
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Continuous  Improvement  Antibodies 


We  tried  that  before 
Our  place  is  different 
It  costs  too  much 
That’s  not  my  job 
They’re  too  busy  to  do  that 
We  don’t  have  the  time 
Not  enough  help 
It’s  too  radical  a  change 
The  staff  will  never  buy  it 
It’s  against  company  policy 
The  union  will  scream 
Runs  up  our  overhead 
We  don’t  have  the  authority 
Let’s  get  back  to  reality 
That’s  not  our  problem 
I  don’t  like  the  idea 
You’re  right,  but... 

You’re  two  years  ahead  of  you  time 
We’re  not  ready  for  that 
It  isn’t  in  the  budget 
Can’t  teach  an  old  dog  new  tricks 
Good  thought,  but  impractical 
Let’s  give  it  more  thought 
We’ll  be  the  laughingstock 
Not  that  again 


Where’d  you  dig  that  one  up? 

We  did  all  right  without  it 
It’s  never  been  tried  before 
Let’s  put  that  one  on  the  back  burner 
Let’s  form  a  committee 
I  don’t  see  the  connection 
It  won’t  work  in  our  plant/office 
The  committee  would  never  go  for  it 
Let’s  sleep  on  it 
It  can’t  be  done 

It’s  too  much  trouble  to  change 
It  won’t  pay  for  itself 
It’s  impossible 
I  know  a  person  who  tried  it 
We’ve  always  done  it  this  way 
Top  management  won’t  buy  it 
We’d  lose  money  in  the  long  run 
Don’t  rock  the  boat 
That’s  all  we  can  expect 
Has  anyone  else  ever  tried  it? 

Let’s  look  into  it  further  (later) 

Quit  dreaming 

That  won’t  work  in  our  school 
That’s  too  much  ivory  tower 
It’s  too  much  work 
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The  Ten  Challenges  ■, 

The  Ten  Challenges,  as  discussed  in  The  Dance  of  Change  by  Peter  Senge 
copied  from  http://www.qwsae.ora/ThouqhtLeaders/SengeTenChallenqes.htm 

Challenges  of  Initiating 

These  challenges  are  often  sufficient  to  prevent  growth  from  occurring,  almost  before  it  starts.  They  are 
consistently  encountered  at  the  early  stages  of  significant  organizational  change.  The  capabilities  to  deal 
with  them  must  be  developed  under  high  pressure;  but  in  managing  these  challenges  effectively, 
organizations  develop  capabilities  much  sooner  than  otherwise  for  dealing  with  challenges  down  the  road. 

1  Not  Enough  Time:"We  don’t  have  time  for  this  stuff!" 

This  is  the  challenge  of  control  over  one’s  time.  This  challenge  is  represents  a  valuable  opportunity  for 
reframing  the  way  that  workplaces  are  organized,  to  provide  flexibility  and  time  for  reflection  and 
innovation. 

2  No  Help:  "We’re  like  the  blind  leading  the  blind!'' 

Some  managers  believe  that  asking  for  help  is  a  sign  of  incompetence;  others  are  unaware  of  the 
coaching  and  support  they  need.  Meeting  this  challenge  means  building  the  capabilities  for  finding  the  right 
help,  and  for  mentoring  each  other  to  develop  successful  innovations. 

3  Not  Relevant:  "Why  are  we  doing  this  stuff?" 

A  top  priority  for  pilot  groups  is  a  clear,  compelling  case  for  learning  and  change.  If  people  are  not 
sufficiently  committed  to  an  initiative’s  goals,  a  "commitment  gap"  develops  and  they  will  not  take  part 
wholeheartedly.  Building  relevance  depends  on  candid  conversations  about  the  reasons  for  change  and 
the  commitments  people  can  make. 

4  "Walking  the  Talk"  -  Leadership  values 

What  happens  when  there  is  a  mismatch  between  the  things  the  boss  says  and  his  or  her  actual  behavior? 
People  do  not  expect  perfection,  but  they  recognize  when  leaders  are  not  sincere  or  open.  If  executive  and 
line  leaders  do  not  provide  an  atmosphere  of  trust  and  authenticity,  then  genuine  change  cannot  move 
forward. 

©  2003  by  Carnegie  Mellon  University 


page  152 


CarnecpeMellon 

Software  Engineering  Institute 


LOCKHEED  MARTIN  X 


The  Ten  Challenges  2 

Challenges  of  Sustaining  Momentum 

These  challenges  occur  sometime  during  the  first  year  or  two,  when  the  group  has  clear  goals  and  has 
discovered  that  new  methods  save  more  than  enough  time  to  put  them  into  practice.  Now  the  pilot 
group’s  real  troubles  begin.  Sustained  activity  confronts  boundaries  -  between  the  work  of  the  pilot 
group  and  "internal"  attitudes  and  beliefs,  and  between  the  pilot  group’s  needs  and  the  larger-scale 
company’s  values  and  ways  of  measuring  success. 

5  Fear  and  Anxiety:  "This  stuff  is  — " 

The  blanks  represent  the  fact  that  everyone  expresses  their  fear  and  anxiety  with  a  different  form  of 
defensiveness.  How  do  you  deal  with  the  concerns  of  team  members  about  exposure,  vulnerability  and 
inadequacy,  triggered  by  the  conflicts  between  increasing  levels  of  candor  and  openness  and  low 
levels  of  trust?  This  is  one  of  the  most  frequently  faced  challenges  and  the  most  difficult  to  overcome. 

6  Assessment  and  Measurement:  "This  stuff  isn’t  working" 

How  do  you  deal  with  the  disconnect  between  the  tangible  (but  unfamiliar)  achievements  of  a  pilot 
group  and  the  organization’s  traditional  ways  of  measuring  success? 

7  Believers  and  Nonbelievers:  "We  have  the  right  way!"  say  pilot  group  members.  "They’re  acting 
like  a  cult!"  say  their  other  colleagues  and  peers. 

Riding  on  a  wave  of  early  success,  speaking  their  own  language,  the  pilot  group  becomes  increasingly 
isolated  from  the  rest  of  the  organization.  Outsiders,  meanwhile,  are  put  off  and  then  turned  off  by  the 
new,  unfamiliar  approaches  and  behavior.  These  misunderstandings  easily  accelerate  into 
unnecessary,  but  nearly  unavoidable,  opposition. 
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The  Ten  Challenges  3 

Challenges  of  System  wide  Redesign  and  Rethinking 

These  challenges  appear  as  a  pilot  group’s  work  gains  broader  credibility  and  confronts  the 
established  internal  infrastructure  and  practices  of  the  organization. 

8  Governance:  "They  won’t  give  up  the  power." 

As  the  pilot  group’s  capabilities  and  activities  increase,  it  runs  into  the  priorities  and  established 
processes  of  the  rest  of  the  organization.  This  leads  to  conflicts  over  power  and  autonomy  and  to  a 
destructive,  "us-versus-them"  dynamic  that  nobody  wants  -  and  that  could  be  avoided  if  the  capabilities 
are  in  place  for  organizational  redesign. 

9  Diffusion:  "We  keep  reinventing  the  wheel!" 

Unless  organizations  learn  to  recognize  and  deal  with  their  mysterious,  almost  unnoticed  inability  to 
transfer  knowledge  across  organizational  boundaries,  people  around  the  system  will  not  build  upon 
each  other’s  successes. 

10  Strategy  and  Purpose:  "Where  are  we  going?  and  "What  are  we  here  for?" 

How  do  you  revitalize  and  rethink  the  organization’s  intended  direction  for  success,  its  contribution  to 
its  community  and  its  future  identity?  How  do  you  improve  the  processes  of  conversation  that  lead 
people  to  articulate  and  refine  their  aspirations  and  goals  for  achieving  them? 

NOTE:  This  material  is  drawn  from  The  Dance  of  Change  and  The  Fifth  Discipline  Fieldbook  Project  site. 
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Addendum 

Additional  reading 

Additional  analytical  tools:  abbreviated  “tool  tips” 
Additional  illustration 
Change  Agent  References 

CMMI  Process  Areas 
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CMMI  Structure 


Appendixes 


Maturity  Level  5 
OID,  CAR 


Maturity  Level  4 
OPP,  QPM 


Maturity  Level  3 
REQD,  TS,  PI,  VER, 
VAL,  OPF,  OPD,  OT, 
IPM,  RSKM,  PAR 


Maturity  Level  2 
REQM,  PP,  PMC, 
SAM,  MA,  PPQA,  CM 


Front  Matter 
Introduction 
Structure  of  the  Model 
Model  Terminology 

Maturity  Levels,  Common  Features,  and  Generic 
Practices 

Understanding  the  Model 
Using  the  Model 


CMMI-SE/SE 

Staged 
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Support 

CM,  PPQA,  MA, 
CAR,  DAR 

Engineering 

REQM,  REQD,  TS, 
PI,  VER,  VAL 


Project  Management 
PP,  PMC,  SAM 
IPM,  RSKM,  QPM 


Process  Management 
OPF,  OPD,  OT, 
OPP,  OID 


Front  Matter 
Introduction 
Structure  of  the  Model 
Model  Terminology 
Capability  Levels  and  Generic  Model 
Components 

Understanding  the  Model 
Using  the  Model 


CMMI-SE/SW 

Continuous 
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CMMI 

Process 

Areas 


Category 

Process  Areas 

Process 

Management 

Organizational  Process  Focus  (OPF) 
Organizational  Process  Definition  (OPD) 
Organizational  Training  (OT) 

Organizational  Process  Performance  (OPP) 
Organizational  Innovation  and  Deployment  (OID) 

Project 

Management 

Project  Planning  (PP) 

Project  Monitoring  and  Control  (PMC) 

Supplier  Agreement  Management  (SAM) 

Integrated  Project  Management  (IPM) 

Risk  Management  (RSK) 

Quantitative  Project  Management  (QPM) 

Engineering 

Requirements  Management  (REQM) 

Requirements  Development  (RD) 

Technical  Solution  (TS) 

Product  Integration  (PI) 

Verification  (VER) 

Validation  (VAL) 

Support 

Configuration  Management  (CM) 

Process  and  Product  Quality  Assurance  (PPQA) 
Measurement  and  Analysis  (MA) 

Causal  Analysis  and  Resolution  (CAR) 

Decision  Analysis  and  Resolution  (DAR) 
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